POV-Ray : Newsgroups : povray.off-topic : Oh dear... : Re: Oh dear... Server Time
6 Sep 2024 19:18:36 EDT (-0400)
  Re: Oh dear...  
From: Darren New
Date: 12 Nov 2008 12:47:32
Message: <491b16b4@news.povray.org>
Invisible wrote:
> I'd hate to write a long email explaining what a 
> smart-arse I am and then discover that I got some small technical detail 
> wrong and actually the other guy was right all along.

This is how you manage these things:

Pretend you're not as smart as the person you're talking to, and you 
don't know as much. (I'll make it short and over-the-top to illustrate, 
but of course if you turn it into two pages you don't need to make it 
sound smarmy.) Assume that the guy is not stupid, but that he has 
requirements you aren't aware of.

"""
Thanks. I looked over your backup plans, and I'd like to understand more 
why your method is superior. I've been using backup method B, which as 
you know saves all the metadata and makes it quick to restore in the 
event of a disaster. I thought this was why we were making the backups, 
but perhaps I'm misinformed.

You're suggesting that we switch to backup method E, which has the 
advantage of letting us restore to later versions of oracle but would 
seem to have the disadvantage that it would take much more effort to 
recover from a disaster. For example, since method E does not save the 
user account information, we would still need to export that 
independently at the time of making backups with method E or risk 
needing to recreate that information while the company waits.

Perhaps the best approach would be to take backup method E each month, 
and backup method B each day (since B allows rolling back to any 
previous point in time), and save the monthly of each indefinitely. This 
would seem to be the best of both worlds.

Please clarify how you would like me to handle the following situations 
using backup method E:
1) Saving user account information in a secure way,
2) Which triggers should be enabled if data needs to be restored,
3) Whether indecies should be included in the exports,
4) How often we should do exports to insure we don't overflow 
transaction buffer pools,
5) ... anything else you think is problematic ...
"""

The first part says "Oh, have we changed what we're doing? Is that why 
you're changing stuff that works?"

The second says "I know there are advantages to your way of doing it, 
but there are disadvantages, and you job is to weigh them and figure out 
whether it's worth the risk to get the advantages."

The third part says "Here's a way to save face and not look like an 
idiot by reversing yourself. We can still make backups the way you want, 
and just not use them. And three months from now, when the system 
becomes unusable for an hour in the middle of the day because of your 
backups, you can tell me to stop doing it that way, as if I hadn't told 
you that in the first place three months ago."

The fourth is "Please put in writing all the solutions to the problems 
you're causing, so I don't get blamed. If you don't know what I'm 
talking about, understand that I know more about this than you, and 
hence maybe you should take my advice."

But if you do it politely, careful of his ego and humble in your 
criticism, it works pretty well. If you say "please explain to this poor 
ignorant peon why you're making such a boneheaded decision", you not 
only look better in the event that you're wrong, but you haven't ticked 
him off by being right. Especially if it goes back and forth a couple 
times, with him changing his story a little each time until he has been 
agreeing with you all along. :-)

-- 
Darren New / San Diego, CA, USA (PST)


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.